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the "From:" and "Sender:" Header Fields 


Abstract 


The Internet Message Format (RFC 5322) allows "group" syntax in some 
email header fields, such as "To:" and "CC:", but not in "From:" or 
"Sender:". This document updates RFC 5322 to relax that restriction, 
allowing group syntax in those latter fields, as well as in 
"Resent-From:" and "Resent-Sender:", in certain situations. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6854. 
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document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
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1. Introduction 


The Internet Message Format, as far back as RFC 822 [RFC0822], has 
always required a usable address to appear in the "From:" header 
field of messages in order to allow replies to be sent. To this end, 
the syntax of messages, up to and including the current specification 
[RFC5322], has required the use of the mailbox address form in the 
originator ("From:" and "Sender:") fields of messages and has 
specifically forbidden the use of the group address form, which 
permits an empty list of addresses (that is, an address list with no 
address included that might be used for a reply). 


However, the use cases for the "From:" field have evolved. There are 
numerous instances of automated systems that wish to send email but 
cannot handle replies, and a "From:" field with no usable addresses 
would be extremely useful for that purpose. More recently, work with 
internationalized email addresses [RFC6530] creates a real need to 
take a message with an internationalized email address and hand it to 
an older client that would have no ability to reply to such an 
address but might still wish to display the contents of the message. 
The group construct provides an existing syntax for unusable 
addresses (using the empty list of addresses) and also allows for a 
text label that describes the originator. For example: 


From: Automated System:; 


A review of many current email programs finds that all reviewed 
clients will properly display a message with group syntax in the 
"From:" field. At worst, such programs generate an error message 
when an attempt is made to reply to such a message. No other 
interoperability problems have been discovered. 
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This document therefore updates the Internet Message Format 
specification [RFC5322] to relax that restriction, allowing group 
syntax to be used in the originator ("From:" and "Sender:") fields, 
as well as in their corresponding resent ("Resent-From:" and 
"Resent-—Sender:") fields. This change permits empty groups, as 
described above, and also permits named groups of mailboxes (groups 
with non-empty lists of addresses; see Section 4). Nevertheless, 
this document recommends against the general use of group syntax in 
these fields at this time (see Section 3). 


1.1. Notational Conventions 


The notational conventions here are the same as those in RFC 5322, 
and the following two subsections are copied directly from that 
document. 


1.1.1. Requirements Notation 


This document occasionally uses terms that appear in capital letters. 
When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD 
NOT", and "MAY" appear capitalized, they are being used to indicate 
particular requirements of this specification. A discussion of the 
meanings of these terms appears in the Key Words document [RFC2119]. 


1.1.2. Syntactic Notation 


This specification uses the Augmented Backus-Naur Form (ABNF) 
[RFC5234] notation for the formal definitions of the syntax of 
messages. Characters will be specified either by a decimal value 
(e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by 
a case-insensitive literal value enclosed in quotation marks (e.g., 
"A" for either uppercase or lowercase A). 


2. Allowing Group Syntax in "From:" and "Sender:" 


Section 3.6.2 of RFC 5322 defines the "From:" header field as 


containing a <mailbox-list> syntax element. This specification 
changes that definition to use the <address-list> syntax element, as 
is used in other fields, such as "To:", "CC:", and "Reply-To:". This 


specification also changes the definition of the "Sender:" header 
field from the <mailbox> syntax element to the <address> syntax 
element. While the <address> element includes the <mailbox> element 
already, we have chosen to specify both in the updated syntax as a 
way of highlighting the limited use intended for the change (see 
Section 3). 
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Section 2.1 below is a full replacement for Section 3.6.2 of RFC 
5322, containing the new syntax as well as a new description of the 
semantics for the "From:" and "Sender:" fields. Section 2.2 below is 
a replacement of only the ABNF syntax for the "Resent-From:" and 
"Resent—-Sender:" fields in Section 3.6.6 of RFC 5322; the rest of the 
syntax as well as the descriptive text of Section 3.6.6 of RFC 5322 
remains unchanged. 


[The text in the following section is not consistent within itself 
nor with the rest of this document in how it refers to message header 
fields, sometimes putting the field name in quotation marks and 
sometimes not, sometimes capitalizing the field name and sometimes 
not, and sometimes including the final colon and sometimes not. 
Because minimizing changes to the original text is more important, in 
this case, than attaining consistency, the text in Section 2.1, as 
well as that in Sections 1.1.1 and 1.1.2 above, is left as it was in 
RFC 5322.] 


2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields 


The originator fields of a message consist of the from field, the 
sender field (when applicable), and optionally the reply-to field. 
The from field consists of the field name "From" and a 
comma-separated list of one or more addresses (either mailbox or 
group syntax). If the from field contains more than one mailbox 
specification (including all mailboxes included in any groups), then 
the sender field, containing the field name "Sender" and a single 
address, MUST appear in the message. The from field and the sender 
field SHOULD NOT use group syntax; rather, the from field SHOULD use 
only the mailbox-list syntax and the sender field SHOULD use only 
mailbox syntax (see RFC 6854, Section 3). If the sender field uses 
group syntax, the group MUST NOT contain more than one mailbox. In 
either case, an optional reply-to field MAY also be included, which 
contains the field name "Reply-To" and a comma-separated list of one 
or more addresses. 


from = "From:" (mailbox-list / address-list) CRLF 
sender = "Sender:" (mailbox / address) CRLF 
reply-to = "Reply-To:" address-list CRLF 


The originator fields indicate the mailbox(es) of the source of the 


message. The "From:" field specifies the author(s) of the message, 
that is, the mailbox(es) of the person(s) or system(s) responsible 
for the writing of the message. The "Sender:" field specifies the 


mailbox of the agent responsible for the actual transmission of the 
message. For example, if a secretary were to send a message for 
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another person, the mailbox of the secretary would appear in the 
"Sender:" field and the mailbox of the actual author would appear in 
the "From:" field. If the originator of the message can be indicated 
by a single mailbox and the author and transmitter are identical, the 
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD 
appear. 


Note: The transmitter information is always present. The absence 
of the "Sender:" field is sometimes mistakenly taken to mean that 
the agent responsible for transmission of the message has not been 
specified. This absence merely means that the transmitter is 
identical to the author and is therefore not redundantly placed 
into the "Sender:" field. 


The originator fields also provide the information required when 
replying to a message. When the "Reply-To:" field is present, it 
indicates the address(es) to which the author of the message suggests 
that replies be sent. In the absence of the "Reply-To:" field, 
replies SHOULD by default be sent to the mailbox(es) specified in the 
"From:" field unless otherwise specified by the person composing the 
reply. 


In all cases, the "From:" field SHOULD NOT contain any mailbox that 
does not belong to the author(s) of the message. See also Section 
3.6.3 of RFC 5322 [RFC5322] for more information on forming the 
destination addresses for a reply. 


-2. Update to RFC 5322, Section 3.6.6. Resent Fields 
This section updates RFC 5322, Section 3.6.6, to allow groups (via 
the address-list ABNF production) in the "Resent-From:" and 
"Resent-—Sender:" fields, to parallel the change to "From:" and 
"Sender:" above. The ABNF for these fields is changed as follows: 


resent-from = "Resent-From:" (mailbox-list / address-list) CRLF 


resent-sender = "Resent-Sender:" (mailbox / address) CRLF 
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3. Applicability Statement 


Mailbox syntax is the normal syntax to use in the "From:" and 
"Sender:" header fields; the address syntax defined in Section 2.1, 
which allows the specification of a group, is only for Limited Use 
(see RFC 2026 [RFC2026], Section 3.3, item (d)) for the reasons 
described below. 


Many Internet email procedures and much software assumes that the 


addresses in the "From:" and "Sender:" fields can be replied to and 
are suitable for use in organizing and filtering mail. The use of 
groups instead of mailboxes can disrupt these uses. Consequently, 


while this specification legitimizes the use of groups, it does so 
only to enable circumstances when that use is necessary. Because the 
use of this mechanism is new, it is important that its use be limited 
to these circumstances and that it be used with caution. In 
particular, user agents SHOULD NOT permit the use of groups in those 
fields in outgoing messages. 


4. Examples 


First, consider an email message that is sent by an automated nightly 
monitor program, to which replies should not be sent. Such messages 
commonly include a valid, replyable address that will discard any 
replies that are sent to it, but recipients who do reply might be 
unaware that their replies will be discarded. If the message is 
instead presented as follows, the recipients’ email clients will not 
allow them to reply in the first place: 


From: Nightly Monitor Robot:; 
Second, consider an email message that is meant to be "from" the two 
managing partners of a business, Ben and Carol, and that is sent by 
their assistant, Dave. This message could always have been presented 


this way: 


From: ben@example.com, carol@example.com 
Sender: dave@example.com 


This change allows it to be represented this way: 


From: Managing Partners:ben@example.com, carol@example.com; 
Sender: dave@example.com 
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3% 


Security Considerations 


See the Internet Message Format specification [RFC5322] for general 
discussion of security considerations related to the formatting of 
email messages. 


The "From:" address is special, in that most user agents display this 
address, or the "friendly" text associated with it, to the end user, 
and label it so as to identify it as the origin of the message (as 


implied in Section 3.6.2 of RFC 5322). Group syntax in the "From:" 
header field can be used to hide the identity of the message 
originator. It is just as easy to use a fabricated "From:" address 


to accomplish the same thing, so allowing groups in this field does 
not exacerbate the security problem. 


Some protocols attempt to validate the originator address by matching 
the "From:" address to a particular verified domain (for one such 
protocol, see the Author Domain Signing Practices (ADSP) document 
[RFC5617]). Such protocols will not be applicable to messages that 
lack an actual email address (whether real or fake) in the "From:" 
field. Local policy will determine how such messages are handled, 
and senders, therefore, need to be aware that using groups in the 
"From:" might adversely affect deliverability of the message. 


Because groups have previously not been allowed in the "From:" and 
"Sender:" header fields, it is possible that some implementations 
that conform to RFC 5322 might not be prepared to handle the group 
syntax, and, indeed, might not even recognize that group syntax is 
being used. Of those implementations, some subset might, when 
presented with group syntax in those header fields, behave in a way 
that is exploitable by an attacker. It is deemed unlikely that this 
will be a serious problem in practice: address field parsing is 
generally an integral component of implementations, and address field 
parsers are required to understand group syntax. In addition, if any 
implementations should be exploitable through this mechanism, it is 
already possible for attackers to do it by violating RFC 5322. Other 
violations of RFC 5322 are commonly used by malefactors. 
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6. IANA Considerations 


IANA has updated the "Permanent Message Header Field Names" registry 
to include this document as a reference as follows: 


OLD 

tesse a Sosa SSSass toSSesans a Pa eee a ae Par sa ae ie EE ee + 
From mail standard | [RFC5322] 

E SSeS SSS FASS SES A Sa E + 

toss toa 7a sae toe aaa Sees eas ae + 
Sender | mail standard | [RFC5322] 

toss toa E toasts i ener ennai nn + 

tars toa aa trenean a A O E + 
Resent-From | mail standard | [RFC5322] 

PSS Hasse E N toa aa a Se ira a a iPS SS Heals a ae ee + 

Peor caren actrees Peena sae deta esas Cas Ae A ot + 
Resent-Sender | mail standard | [RFC5322] 

PSS res S SSS sre Sss : aed ae oats $e See Sea aaa ee + 

NEW 

tars A a sae ta + 
From | mail standard | [RFC5322] [RFC6854] 

tas Teong eos Tereon e E + 

E Foenn S n a et aa PSSe eae Se ae ee ees + 
Sender | mail standard | [RFC5322] [RFC6854] 

tose see a toa aa oa i ta arg a 5 ents ae ee gga en ee + 

POSR aS sel Seaasss toa aa $a rSsssssEe Hs Gan a la ata a alle decree + 
Resent-From | mail standard | [RFC5322] [RFC6854] 

5 ta aca ke a etchant as toa aaa sae Heep a wr i Aa ae + 

toss toa aa toasts ta + 
Resent-Sender | mail standard | [RFC5322] [RFC6854] 

tans toa aa Sele ta + 
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